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4 CONVERTING A DOWNLOADED PROGRAM FRAGMENTS -FRAGMENTS WITH DATA 

5 TYPES RESTRICTIONS AND 

6 CORRESPONDING SYSTEMS SYSTEM 
7 

8 BACKGROUND OF THE INVENTION 

9 1 , Field of the invention 

10 The invention relates to a protocol process for managing, a method of verifying and a 

1 1 method of transforming a downloaded program fragment and the corresponding systems, more 

12 particularly intended for on board embedded data-processing systems having f e w r e sourc e s 

1 3 availabl e in t e rms o f with limited memory and of computing powe r resources . 

14 Z Prior Art 

15 In a general way, by reference to 6gt*F eFigure la, it is reiterated that on boar d embedded 

16 data-processing systems 10 include a microprocessor 11, a permanent memory, such as a non- 
17 writable memory 12 containing the code of the executable program, and a rewritable, nonvolatile, 

1 8 permanent memory 4#13 of EEPROM type containing the data stored in the system, a volatile, 

19 random-access memory 14 in which the program stores its intermediate results while it is 

20 executing, and input/output devices 15 allowing the system to interact with its environment— la. 

21 When the cas e in which th e on boar d embedded data-processing system consists of a 

22 microprocessor card, of the bank-card type, the input/output device 1 5 consists of a serial link 

23 allowing the card to communicate with a terminal, such as a card-reader terminal. 

24 In conventional on board embedded data-processing systems, the code of the program 

25 executed by the system is fixed during construction of the system, or, at the latest, when the latter 

26 is customized before delivery to the final user. 
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1 More sophisticated on boar d embedded data-processing systems have, however, been 

2 implemented, these systems being reprogrammable, such as microprocessor cards of the 

3 JavaCard JAVACARD type, for example. With r e sp e c t Compared to the pr e c e ding earlier types, 

4 these reprogrammable systems add the possibility of enhancing the program after the system has 

5 been put into service, via an operation of downloading program fragments. These program 

6 fragments of programs, wid e ly designat e d b y , commonly known as "applets", will be 

7 d e signat e d referred to as applets or program fragments indiscriminately in the present description. 

8 For a more detailed description of JavaCard JAVACARD systems, reference could usefully be 

9 made to the documentation published by the company SUN MICROSYSTEMS INC., and in 

10 particular to the electronically available documentation, JavaCard JAVACARD technology 

11 chapter, on the www (World Wide Web 4 at site http:_ 

1 2 //java.sun.com/products/javacard/index.html, available since June 1 999. 

13 flguF eFigure lb illustrates the architecture of such a reprogrammable on boar d embedded 

14 data-processing system. This architecture is similar to that of a conventional on boar d embedded 

15 system, wk hapart from the diff e renc efact that the reprogrammable on boar d embedded system 

16 can mor e ov e r in addition receive applets by way ofv ia one of its input/output devices, then store 

17 them in its permanent memory 13 from which they can then be executed as a suppl e m e nt 

1 8 t ecomplementing the main program. 

19 For reasons of portability between different on boar d embedded data-processing systems, 

20 applets ar e pr e s e nt e d in take the form of code for a standard virtual machine. This code is not 

21 directly executable by the microprocessor 1 1, but it has to be interpreted in software terms by a 

22 virtual machine 16, which consists of a program resident in a non- writable permanent memory 

23 12. In the abovementioned example of JavaCard JAVACARD cards, the virtual machine used is 
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1 a subset of the fevaJAVA virtual machine. For a description of the specifications relating to the 

2 Jav aJAVA virtual machine and of the virtual machine used, reference could usefully be made to 

3 the work published by Tim LINDHOLM and Frank YELLIN, entitled "The Java Virtual Machine 

4 Specification/ \ Addison- Wesley 1996, and to the documentation published by the company SUN 

5 MICROSYSTEMS INC. " JavaCar d JAVACARD 2.1 Virtual Machine Specification", 

6 documentation available electronically on the ww wWorld Wide Web at site 

7 http://java.sun.com/products/javacard/JCVMSpec.pdf, since M arch 1999. 

8 The operation of downloading applets onto an on boar d embedded data-processing system 

9 in service poses considerable security problems. An applet which is involuntaril y unintentionally , 

10 or even deliberately, badly written may incorrectly modify data present on the system, prevent the 

1 1 main program from e x e cutin gb eing executed correctly or at the right time, or els eeven modify 

12 other applets downloaded previously, making them unusable or harmful. 

13 An applet written by a computer hacker may also divulge confidential information stored 

14 in the system, information such as the access code in the case of a bank card, for example. 

15 At the present time, three solutions have been proposed with a view to remedying the 

1 6 problem of apglet_securit y of appl e ts . 

17 A first solution consists in using cryptographic signatures^-se-a s in order to accept only 

1 8 applets originating from trusted bedie sorganizations or persons. 

19 In the abovementioned example of a bank card, only the applets bearing the cryptographic 

20 signature of the bank having issued the card are accepted and executed by the card, any other 

21 unsigned applet being rejected in the course of the downloading operation. An ill-intentioned 

22 user of the card, not having available encryption keys from the bank, will therefore be incapabl e 

23 of e x e cutin g unable to execute an unsigned and dangerous applet on the card. 
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1 This first solution is well adapt e d suited to the case where all the applets originate from 

2 the same single source, the bank in the abovementioned example. This solution is difficult to 

3 apply in the case in whic h where the applets originate from several sources, such as, in the 

4 example of a bank card, the card_manufacture r of the card , the bank, the bedie sorganizations 

5 managin g s e rvic e s by bank car d services , the large commercial distribution organizations 

6 offering cli e nt e l ecustomers loyalty programs and proposing, legitimatelv r offering to download 

7 specific applets onto the card. The sharing and the holding among these various economic 

8 participants of the encryption keys necessary for the electronic signature of the applets pose 

9 major technical, economic and legal problems. 

10 A second solution consists in carrying out dynamic ch e cks on access and en-typing during 

1 1 th e e x e cution o f checks while executing the applets. 

12 In this solution, the virtual machine carries out a certain number of checks, during th e 

1 3 e x e cution o fw hile executing the applets, such as: 

14 • ch e ck o fi nemory access to th e m e mor y check : upon each read or write in a memory 

15 area, the virtual machine verifies the right of access by the applet to the corresponding data; 

16 • dynamic verification of the data types: upon each instruction from the applet, the 

17 virtual machine verifies that the constraints on the data types are satisfied. By way of example, 

18 the virtual machine may hav eapply special handling fo r processing to data such as valid memory 

19 addresses, and prevent the applet generating invalid memory addresses by way of integer/address 

20 conversions or arithmetic operations on the addresses; 

21 • detection of stack overflows and of illegal accesses to the execution stack of the 

22 virtual machine, which, under certain conditions, are likely to disturb the operation thereof, to the 

23 point of circumventing the preceding check mechanisms. 
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1 This second solution allows execution of a wide range of applets under satisfactory 

2 security conditions. However, it f e atur e s presents the drawback of a considerable slowing of the 

3 execution, caused by the range of dynamic verifications. In order to obtain a reduction in this 

4 slowin g effect , some of these verifications can be tak e n charg e o fm anaged by the microprocessor 

5 itself, at the cost, however, of an increase in the complexity thereof and thus of the cost price of 

6 the on board embedded system. Such verifications furthermore increase the requir e m e nts for 

7 random-access and permanent memory requirements of the system, by r e a s o nb ecause of the 

8 additional type information which it is n e c e ssary to associat emust be associated with the data 

9 handled. 

10 A third solution consists in carrying out a static verification of the code of the applet 

1 1 during the downloading. 

12 In this solution, this static verification simulates the execution of the applet at the level of 

13 the data types and establishes, once and for all, that the code of the applet complies with the rule 

14 of data types and of access control imposed by the virtual machine and does not cause a stack 

15 overflow. If this static verification is successful, the applet can then be executed without it being 

16 necessary dynamically to verify that this rule is complied with. In the event that the static 

17 verification process fails, the on boar d embedded system rejects the "applet" and does not allow 

18 its subsequent execution. For a more detailed description of the abovementioned third solution, 

19 reference could usefully be made to the work published by Tim LINDHOLM and Frank YELLIN 

20 quoted above, to the article published by James A. GOSLING entitled "Java Intermediate Byte 

21 Codes", proceedings of the ACM SIGPLAN, Workshop on Intermediate Representations 

22 (IR'95), pages 111-118, January 1995, and to the US patent 5,748,964 granted on 05/05/1998. 
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1 Compared with the second solution, the third solution presents the advantage of a much 

2 more rapid execution of the applets, since the virtual machine does not carry out any verification 

3 during execution. 

4 The third solution, however, f e atur e s presents the drawback of a process of static 

5 verification of the code which is complex and expensive, both in terms of size of code necessary 

6 to conduct this process and in terms of size of random-access memory necessary to contain the 

7 intermediate results of the verification, and in terms of computation time. By way of illustrative 

8 example, the code verification int e grat e d into incorporated in the Jav aJAVA JDK system 

9 marketed by SUN MICROSYSTEMS represents about 50 byte skbytes of machine code, and its 

10 consumption in terms of random-access memory is proportional to (Tp + Tr) x Nb, where Tp 

1 1 designates the maximum stack space, Tr designates the maximum number of registers and N^Nb 

12 designates the maximum number of branchin gb ranch targets used by a subpro gra m subroutine . 

13 also wid e ly d e signat e d b y commonly called method, of the applet. These memory requirements 

14 greatly e xc ee d e d exceed the capacities of the resources of th e majority of th e most present-day en- 

15 beaf dembedded data-processing systems, especially of commercially available microprocessor 

16 cards. 

17 Several variants of the third solution have been proposed, in which the wFke rpublisher of 

18 the applet sends to the verifier, in addition to the code of the applet, a certain amount of specific 

19 supplementary information such as precalculated data types or preestablished proof of correct 

20 data typing. For a more detailed description of the corresponding operating mod e sp rocedures . 

21 reference could usefully be made to the articles published by Eva ROSE and Kristoffer 

22 HOGSBR O H0GSBRO ROSE, "Lightweight Bytecode Verification", proceedings of the 

23 Workshop on Formal Underpinning of Jav a JAVA . October 1998, and by George C. NECULA, 
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1 "Proof-Carrying Code", Proceedings of the 24th ACM Symposium on_Principles of 

2 Programming Languages, pages 1 06- 1 1 9, respectively. 

3 This supplementary information makes it possible to verify the code more rapidly and 

4 slightly to reduce the size of the cod e of th e verification program code b ut does not make it 

5 possible, however, to reduce the requirements for random-access memory, e rand even increases 

6 them, very substantially, in the case of the correct-data-typing preestablished-proof information. 

7 SUMMARY OF THE INVENTION 

8 The object of the present invention is to remedy the abovementioned drawbacks of the 

9 prior art. 

10 In particular, one subject of the present invention is the implementation of a 

1 1 protocol process for managing a downloaded program fragment, or applet, allowing execution of 

12 the latter by an on boar d embedded data-processing system having fe wlimited resources 

13 available, such as a microprocessor card. 

14 Another subject of the present invention is also the implementation of a method of 

15 verifying a downloaded program fragment, or applet, in which a process of static verification of 

16 the code of the applet is conducted when it is downloaded, this process possibly being 

17 ali^^similar, at least in its principle, wkhto the third solution described above, but ininto which 

18 new verification techniques are introduced, so as to allow execution of this verification within 

19 the limits of valu e s of memory size and ef-computation speed value limits imposed by the 

20 microprocessor cards and other low-power on boar d embedded data-processing systems. 

21 Another subject of the present invention is also the implementation of methods of 

22 transforming program fragments of conventional type obtained, for example, by the use of a 

23 Jav aJAVA compiler-e n. into standardized program fragments, or applets, satisfying, a priori, the 
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1 verification criteria of the verification method which is the subject of the invention, with a view 

2 to accelerating the process of verifying and executing th e m at the l e v e l o fl atter in present-day 

3 microprocessor cards or on board embedded data-processing systems. 

4 Another subject of the present invention is, finally, the production of on board embedded 

5 data-processing systems allowin g enabling the implementation of the abovementioned 

6 protocol p rocess for managing and of th e abov e mentioned method of verifying a downloaded 

7 program fragment as well as of data-processing systems allowin g enabling the implementation of 

8 the methods of transforming conventional program fragments, or applets, into standardized 

9 program fragments, or applets, as mentioned above. 

10 The protocol process for managing a downloaded program fragment e ndownloaded to a 

1 1 reprogrammable on board embedded system, which is the subject of the present invention, applies 

12 especially to a microprocessor card equippe d provided with a rewritable memory. The program 

13 fragment consists of an object code, a series of instructions, executable by the microprocessor of 

14 the on board embedded system by wa ymeans of a virtual machine e quipp e d provided with an 

15 execution stack and with local variables or registers manipulated ¥*aby these instructions and 

16 making it possibl eused to interpret this object code. The on board embedded system is 

1 7 interconnected tewith a terminal . 

18 It is noteworthy in that it consists at least, at the level of the on boar d embedded system, in 

19 detecting a command for downloading ef-the program fragment. On a positive response to the 

20 stagestep consisting in detecting a downloadin g download command, it further consists in reading 

21 the object code constituting the program fragment and in temporarily storing this object code in 

22 the rewritable memory. The whole of the object code stored in memory is subjected to a 

23 verification process, instruction by instruction. The verification process consists at least in a 
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1 stage o f step for initializing the type stack and the tabl e of register type stype array representing 

2 the state of the virtual machine at the start of the execution of the temporarily stored object code 

3 and in a succession of stag e s of v e rification steps for verifying , instruction by instruction,-ef the 

4 existence, for each current instruction, of a target, branching brandl-instruction target, target of an 

5 exception handler, and in a verification and an updating of the effect of the current instruction on 

6 the type stack and on the tabl e of register fopesh -type array. In the event of an unsuccessful 

7 verification of the object code, the protocol process which is the subject^ of the invention consists 

8 in deleting the mom e ntarily r e cord e d temporarily stored program fragment, wh e n omitting to 

9 Fe6erdif the latte r is not stored in the directory of available program fragments, and in sending an 

10 error code to the reader. 

1 1 The method of verifying a program fragment downloaded enteto an on boar d embedded 

12 system, which is the subject of the invention, applies e sp e ciall y in particular to a microprocessor 

13 card equipped with a rewritable memory. The program fragment consists of an object code and 

14 includes at least one subprogra m subroutine . a series of instructions, executable by the 

15 microprocessor of the on boar d embedded system by wa ymeans of a virtual machine 

16 e quipp e d provided with an execution stack and with operand registers manipulated by these 

17 instructions, and making it possibl eused to interpret this object code. The on boar d embedded 

1 8 system is interconnected t ewith a reader. 

19 It is noteworthy in that, following the detection of a downloadin g download command and 

20 the storage of the object code constituting the program fragment in the rewritable memory, it 

21 consists, for each subpro gra m subroutine . in carrying out a stag e o f step for initializing the type 

22 stack and the tabl e of register type stype array by data representing the state of the virtual machine 

23 at the start of the execution of the temporarily stored object code, in carrying out a verification of 
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1 the temporarily stored object code instruction by instruction, by discerning the existence, for each 

2 current instruction, ofe a brcmching branch-instruction target, of a target of an exception-handler 

3 call or of a target of a subroutine call, and in carrying out a verification and an updating of the 

4 effect of the current instruction on the data types of the type stack and of the tabl e of register 

5 fepe stype array , on the basis of the existence of a branchin g branch -instruction target, of a target 

6 ofa^subroutine call or of a target of an exception-handler call. The verification is successful 

7 when the tabl e of register type stype array is not modified in the course of a verification of all the 

8 instructions, the verification process being carried out instruction by instruction until the tabl e of 

9 register type stype array is stable, with no modification present. Otherwise the verification 

10 process is interrupted. 

1 1 The method of transforming an object code of a program fragment into a standardized 

12 object code for this same program fragment, which is the subject of the present invention, applies 

13 to an object code of a program fragment in which the operands of each instruction belong to the 

14 data types manipulated by this instruction, the execution stack does not exhibit any overflow 

15 phenomenon and, for each branching branch instruction, the type of the variables of the stack at 

16 this branchin g branch is the same as at the targets of this branching, b ranch. The standardized 

17 object code obtained is such that the operands of each instruction belong to the data types 

18 manipulated by this instruction, the execution stack does not exhibit any overflow phenomenon 

1 9 and the execution stack is empty at each branchin gb ranch -target instruction. 

20 It is noteworthy in that it consists, for all the instructions of the object code, in annotating 

21 each current instruction with the data type of the execution stack before and after the execution of 

22 this instruction, the annotation data being calculated by means of an analysis of the data stream 

23 relating to this instruction, in detecting, within the instructions and within each current 



#4597691 vl 



10 



1 instruction, the existence of branchings branches for which the execution stack is not empty, the 

2 detection operation being carried out on the basis of the annotation data of the type of stack 

3 variables allocated to each current instruction. In th e pr e s e nc e of a_ On detection of a non-empty 

4 execution stack, it further consists in inserting instructions to transfer stack variables on either 

5 side of these branching s branches or of these branchin gb ranch targets in order to empty the 

6 contents of the execution stack into temporary registers before this branchin gb ranch and to 

7 reestablish the execution stack from the temporary registers after this branchin gb ranch , and in not 

8 inserting any transfer instruction otherwise. 

9 This method thus makes it possible to obtain a standardized object code for this same 

10 program fragment, in which the execution stack is empty at each branchin g branch instruction and 

1 1 branching branch-target instruction, in the absence of any modification teof the execution of the 

12 program fragment. 

13 The method of transforming an object code of a program fragment into a standardized 

14 object code for this same program fragment, which is the subject of the present invention, 

15 applies, moreover, to an object code of a program fragment in which the operands of each 

16 instruction belong to the data types manipulated by this instruction, and a operand of given type 

17 written into a register by an instruction of this object code is rerea dread back from this same 

18 register by another instruction of this object code with the same given data type. The 

19 standardized object code obtained is such that the operands belong to the data types manipulated 

20 by this instruction, one and the same data type being allocated to the same register throughout the 

2 1 standardized obj ect code. 

22 It is noteworthy in that it consists, for all the instructions of the object code, in annotating 

23 each current instruction with the data type of the registers before and after the execution of this 
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1 instruction, the annotation data being calculated by means of an analysis of the data stream 

2 relating to this instruction, and in carrying out a reallocation of the original registers employed 

3 with different types, by dividing these original registers into separate standardized registers. One 

4 standardized register is allocated to each data type used. — R e updatin g A reupdating of the 

5 instructions which manipulate the operands which use the standardized registers is carried out. 

6 The protocol process for managing a program fragment, the method of verifying a 

7 program fragment, the methods of transforming object code of program fragments into 

8 standardized object code and the corresponding systems, which are the subjects of the present 

9 invention, find an-application in the development of reprogrammable onboard embedded systems, 

10 such as microprocessor cards, especially in the Java environment. 

11 BRIEF DESCRIPTION OF THE DRAWINGS 

12 They will be better understood on reading the description and on perusing the drawings 

13 below , in which, oth e r than figur e s la and lb relating to th e prior art : 

14 Figure la represents the architecture of a prior art embedded system. 

15 Figure lb represents the architecture of a prior art reprogrammable embedded system. 

16 - Figure 2 represents a flow chart illustrating the protocol process for managing a 

1 7 program fragment downloaded enteto a reprogrammable on boar d embedded system, 

18 Figure 3 a represents, by way of illustration, a flow chart of a method of verifying^ a 

19 downloaded program fragment in accordance with the subject of the present invention, 

20 Figure 3b represents a diagram illustrating data types and sub-typing relationships 

21 implemented by the method of managing and the method of verifying a downloaded program 

22 fragment, which is the subject of the present invention, 
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1 Figure 3c represents a detail of the verification method as claim e d in figur eaccording to 

2 Figure 3a, relating to the managing of a branchin g branch instruction, 

3 Figure 3d represents a detail of the verification method as claim e d in figur eaccording to 

4 Figure 3a, relating to the managing of a subroutine-call instruction, 

5 Figure 3e represents a detail of the verification method as claim e d in figur eaccording to 

6 Figure 3a, relating to the managing of an exception-handler target, 

7 Figure 3f represents a detail of the verification method as claim e d in figur eaccording to 

8 Figure 3 a, relating to the managing of a target of incompatible branchings b ranches . 

9 Figure 3g represents a detail of the verification method as claimed in figur eaccording to 

10 Fi gure 3 a, relating to the managing of an absence of branchin g branch target, 

1 1 Figure 3h represents a detail of the verification method as claim e d in figur eaccording to 

12 Figure 3 a, relating to the managing of the effect of the current instruction on the type stack, 

13 Figure 3i represents a detail of the verification method as claim e d in figur eaccording to 

1 4 Figure 3 a, relating to the managing of a na register read instructio n for r e ading a r e gist e r , 

15 Figure 3j represents a detail of the verification method as claim e d in figur eaccording to 

1 6 Figure 3 a, relating to the managing of a na register write instruction for writing to a r e gist e r , 

17 Figure 4a represents a flow chart illustrating a method of transforming an object code of a 

18 program fragment into a standardized object code for this same program fragment with a 

19 branching branch instruction, respectively a branching branch-target instruction, with an empty 

20 stack, 

21 Figure 4b represents a flow chart illustrating a method of transforming an object code of a 

22 program fragment into a standardized object code for this same program fragment, making use of 

23 typed registers, a single specific data type being attribut e d assigned to each register, 
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1 Figure 5a represents a detail of implementation of the transformation method illustrated 

2 in 6-guf eFigure 4a, 

3 Figure 5b represents a detail of implementation of the transformation method illustrated 

4 in figuf eFigure 4b, 

5 Figure 6 represents a functional diagram of the complete architecture of a system for 

6 d e v e lopm e nt o f developing a standardized program fragment, and of a reprogrammable 

7 microprocessor card allowing implem e ntation of the protocol used to implement the process for 

8 managing and the method of verifying a program fragment in accordance with the subject of the 

9 present invention. 

10 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

11 In general, it is indicated that the protocol process for managing and the method of 

12 verifying and transforming a downloaded program fragment, which is the subject of the present 

13 invention, and the corresponding systems, are implemented thanks to u sing a software 

14 architecture for the_secure downloading and execution of applets on an on board embedded data- 

15 processing system with fe wlimited resources, such as, in particular, microprocessor cards. 

16 In general, it is indicated that the description below concerns the application of the 

17 invention in the context of reprogrammable microprocessor cards of JavaCar d JAVACARD type, 

18 cf. documentation available electronically from the company SUN MICROSYSTEMS INC., 

1 9 JavaCar d JAVACARD Technology heading mentioned previously in the description. 

20 However, the present invention is applicable to any on boar d embedded system which is 

21 reprogrammable by downloading an applet which is written in the code of a virtual machine 

22 including an execution stack, local variables or registers, and of which the execution model is 

23 strongly typed, each instruction of the code of the applet applyin gb eing applied only to specific 
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1 data types. The protocol process for managing a program fragment downloaded enteto a 

2 reprogrammable on boar d embedded system, which is the subject of the present invention, will 

3 now be described in more detail with reference to fl gFig . 2. 

4 With reference to the abovementioned figure, it is indicated that the object code which 

5 makes up the program fragment or applet consists of a series of instructions which can be 

6 executed by the microprocessor of the on board embedded system by means of the 

7 abovementioned virtual machine. The virtual machine mak e s it possibl eis used to interpret the 

8 abovementioned object code. The on boar d embedded system is interconnected t ewith a terminal 

9 via, for instance, a serial link. 

10 With reference to the abovementioned fi gFig . 2, the management protocol p rocess which 

11 is the subject of the present invention consists at least, in the on boar d embedded system, in 

12 detecting a command to download this program fragment in a stage IQO step 100 a. 400100b. 

1 3 Thus, stag e IQ O step 100 a may consist of a stag e o f step for reading the abovementioned command, 

14 and stag e IQ O step 100b may consist o f a stag e o f step for testing the command which has been 

1 5 read and verifying the existence of a downloadin g download command. 

16 On a positive response to the abovementioned stag e IQO step 100 a. 10 0100b effor detecting 

17 a downloadin g download command, the protocol process which is the subject of the present 

1 8 invention subsequentl y then consists in reading, at stag estep 1 01 , the object code which makes up 

19 the relevant program fragment, and temporarily storing the abovementioned object code in the 

20 memory of the on board embedded data-processing system. The abovementioned temporary 

21 stefmgstorage operation can be executed either in the rewritable memory or, if appropriate, in the 

22 random-access memory of the on boar d embedded system, when ihi sthe latter has sufficient 
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1 capacity. The stage o f step for reading the object code and temporarily storing it in the rewritable 

2 memory is designated as loading th e cod e of th e l oad applet code i n 6 gFig . 2. 

3 The abovementioned stagestep is then followed by a stag estep 102 consisting in 

4 submitting the whole of the temporarily stored object code to a process of verification, 

5 instruction by instruction, of the abovementioned object code. 

6 The verification process consists, at least in a stag e o f step for initializing the type stack e£ 

7 types and the tabl e of data type stype array representing the state of the virtual machine at the start 

8 of execution of the temporarily stored object code, and in a succession of stag e s o f steps for 

9 verifying, instruction by instruction, by discerning the existence, for each current instruction, 

10 designated L, of a target such as a branching branch-instruction target designated CIS, a targ e t 

11 e fCIB. an exception-handler call target o r a target of a subroutine call. A verification and 

12 updat eupdating of the effect of the current instruction Is on the type_stack of typ e s and on the- 

1 3 tabl e of register typestype array is carried out. 

14 When the verification has b ee n 103 is successful at stagestep 103 a, the protocol p rocess 

15 which is the subject of the present invention consists in r e cordin g storing > at stag estep 104, the 

16 downloaded program fragment in a directory of available program fragments, and in sending to 

17 the reader, at stagestep 105, a positive reception acknowledgment. 

18 On the other hand, in the case of unsuccessful verification of the object code at stag estep 

19 103b, the protocol process which is the subject of the present invention consists in inhibiting, in a 

20 stagestep 103c, any execution on the on board embedded system of the mom e ntarily 

21 r e cord e d temporarily stored program fragment. The inhibition stagestep 103 c can be 

22 implemented in various ways. As a nonlimiting example, this stag estep can consist in deleting, 

23 at stagestep 106, the mom e ntarily record e d temporarily stored program fragment, without 
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1 r e cording storing this program fragment in the directory of available program fragments and, at 

2 stagestep 107, in sending an error code to the reader. — StagesjSteps 107 and 105 can be 

3 implemented either sequentially after siage ssteps 106 and 104 respectively, or in multitasking 

4 operation with them. 

5 With reference to the same figEig. 2, on a negative response to the stagestep consisting in 

6 detecting a downloadin g download command at stag e lOO step 100b . the protocolp rocess which is 

7 the subject of the present invention consists in detecting, in a stagestep 108, a command to select 

8 an available program fragment from a directory of program fragments and, on a positive response 

9 to stagestep 108, having detected the selection of an available program fragment, in calling, at 

10 stagestep 109, this selected available program fragment in order to execute it.— Stag e Step 109 is 

11 then followed by a stag estep 110 offer executing the called available program fragment by 

12 wa ymeans of the virtual machine, with no dynamic verification of variable types, rights of access 

13 to the objects which are manipulated by the called available program fragment, or overflow of 

14 the execution stack when each instruction is executed. 

15 In the case where a negative response is obtained at stag estep 108, this stagestep 

16 consisting in detecting a command to select a called available program fragment, the 

17 protocol process which is the subject of the present invention consists in proceeding, inat a 

1 8 stagestep 1 1 1 , to process the standard commands of the on boar d embedded system. 

19 Regarding the absence of dynamic verification of type or rights of access to objects of, for 

20 instance, JavaCar d JAVACARD type, it is indicated that this absence of verification does not 

21 compromise the security of the card, because the code of the applet has necessarily successfully 

22 passedundergone verification. 
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1 More specifically, it is indicated that the code verification which is carried out, as claim e d 

2 in accordance with t he method which is the subject of the present invention, on the 

3 microprocessor card or on boar d embedded data-processing system is more selective than the 

4 customary verification of codes for the virtual Jav aJAVA machine as described in the work 

5 entitled "The Java Virtual Machine Specification' 5 which was mentioned previously in the 

6 description. 

7 However, any code of the Ja¥ aJAVA virtual machine which is correct as far as the 

8 traditional Jav a conventional JAVA verifier is concerned can be transformed into an equivalent 

9 code which is capable of passing successfull y undergoing the code verification which is carried 

1 0 out on the microprocessor card. 

1 1 Whereas it is possible to imagine writing directly Jav aJAVA codes which satisfy the 

12 abov e m e ntion e d verification criteria mentione d previously in the context of implementing the 

13 protocol process which is the subject of the present invention, a noteworthy object of the latter is 

14 also the implementation of a method of automatic transformation of any standard JavaJAVA 

15 code into a standardized code for the same program fragment, necessarily satisfying the 

16 verification criteria implemented as mentioned above. The method of transformation into 

17 standardized code, and the corresponding system, will be described in detail subs e quentlyl ater in 

18 the description. 

19 A more detailed description of the method of verifying a program fragment, or applet, in 

20 accordance with the subject of the present invention, will now be given with reference to fi gFig . 

21 3a and the subsequent figures. 

22 In general, it is indicated that the verification method which is the subject of the present 

23 invention can be implemented either as part of the protocol process for managing a program 
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1 fragment which is the subject of the present invention as described above with reference to 

2 fi gFig . 2, or independently, to provide whatever verification process is judged necessary. 

3 In general, it is indicated that a program fragment is made up of an object code including 

4 at least one subpro gra m subroutine . more commonly d e signat e d caUed a method, and is made up 

5 of a series of instructions which can be executed by the microprocessor of the on board embedded 

6 system vi aby means of the virtual machine. 

7 As shown in fi gFig . 3 a, the verification method consists, for each subpro gram subroutine . 

8 in carrying out a stag estep 200 effor initializing the type stack of types and the tabl e of register 

9 type stype array of the virtual machine by data representing the state of this virtual machine at the 

10 start of execution of the object code which is the subject of the v erification. This object code can 

1 1 be stored temporarily as described above with reference to implementation of the protocol process 

1 2 which is the subject of the present invention. 

13 The abovementioned stag estep 200 is then followed by a stagestep 200a consisting in 

14 positioning the reading of the current instruction Mi, index i, on the first instruction of the object 

15 code.-Stag e Step 200a is followed by a stagestep 201 consisting in carrying out a verification of 

16 the abovementioned object code, instruction by instruction, by discerning the existence, for each 

17 current instruction, designated L, of a branching branch-instruction target GJBCffi, of a target of 

18 an exception-handler call, designated CEM, or of a target of a subroutine call CSR. 

19 The verification stag estep 201 is followed by a stag estep 202 effor verifying and updating 

20 the effect of the current instruction Ii on the data types of the type stack of types and of the table 

21 e£-register type stype array , as a function of the existence, for the current instruction which is 

22 pointed atto by another instruction, of a branching branch-instraction target GffiCDB, of a target 

23 of a subroutine call CSR or of a target of an exception-handler call CEM. 
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1 Siag eStep 202 for the current instruction L is followed by a stagestep 203 to test whether 

2 the last instruction has been reached, the test written as: 

3 Ii = last instruction of the object code? 

4 On a negative response to test 203, the process passes to the next instruction 204, written i = i+1, 

5 and to the on return to stagestep 201 . 

6 It is indicated that the abovementioned verification, at stagestep 202, has b ee n is 

7 successful when the tabl e of r egister type stype array is not modified during verification of all the 

8 instructions L which make up the object code. For this purpose, a test 205 of the existence of a 

9 stable state of the tabl e of register types andtype array is provided. This test is written: 

10 3? Stable state of tabl e of register typestype array . 

11 On a positive response to test 205, the_verification has been successful. 

12 On the other hand, in the case where no absence of modification is noticed, the 

13 verification process is repeated and reinitiated by returning to stagestep 200a. It is demonstrated 

14 that the process is guaranteed to end after a maximum of NrxH iterations, where Nr designates 

15 the number of registers used and H designates a constant depending on the subtyping relation. 

16 Various indications concerning the types of variables which ar e manipulated in the course 

17 of the verification process described above with reference to fi gFig . 3a will now be given with 

1 8 reference to figFi g . 3b. 

19 The abovementioned variable types include at least class identifiers corresponding to 

20 object classes which ar e defined in the program fragment which is subjected to verification, 

21 numeric variable types including at least a type-shor t type , an integer coded on p bits, where the 

22 value of p can be 1 6, and a type for the return address of a jump instruction JSR, this address type 

23 being identifi e d as denoted r etaddr, a type-null type relating to references of null objects, a type an 



#4597691 vl 



20 



1 object type r elating to the objects proper, a specific type X representing the intersection of all the 

2 types and corresponding to the ¥atee-zero nullvalue . another specific type T representing the 

3 union of all the types and corresponding to any type of values. 

4 With reference to fi gFig . 3b, it is indicated that all the abovementioned variable types 

5 verify a subtyping relation: 

6 object €€. T; 

7 short, retaddr T; 

8 X 66 null, short, retaddr 

9 A more specific example of a process of verification as illustrated in fig. 3 a will now be 

10 given, with reference to a first e xampl e of a data structur e example , which is shown in tabiearrav 

11 Tl in the annex. 

12 The abovementioned example concerns an applet written in Jav aJAVA code. 

13 The verification process accesses the code of the subprogram subroutine which forms the 

14 applet which is subjected to verification via a pointer to instruction L which is being verified. 

15 The verification process records the size and type of the execution stack at the current 

16 instruction Ij corresponding to saload in the example of the abov e m e ntion e d 

17 TaM eabovementioned Array Tl . 

18 The verification process then feeefd sstores the size and type of the execution stack at the 

1 9 current instruction in the type_stac k of typ e s via its type stack pointer. 

20 As mentioned above in the description, this typ^stac k of typ e s reflects the state of the 

21 execution stack of the virtual machine at the current instruction Ii. In the example shown in 

22 taM earray Tl, at the time of the future execution of instruction L, the stack will contain three 

23 entries: a reference to an object of class C, a reference to a tabl e of int e g e rs an integer array 
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1 coded on p = 16 bits, the type short [ ], and an integer of p = 16 bits of type short. This is also 

2 shown in the type stack, which also contains three entries: C, the type o f the objects of class C, 

3 short [], the type of taMe sthe arrays of integers p = 16 bits and short, the type of integers p = 16 

4 bits. 

5 Another noteworthy data structure consists of a tabl e of aa register fepe stype array , this 

6 tabl earray reflecting the state of the registers, that is to say of the registers which store the local 

7 variables, of the virtual machine. 

8 Continuing the example indicated in tablearray Tl, it is indicated that entry 0 of the tabl e 

9 ef-register tvpe stype array contains type C, i.e. at the time of the future execution of the current 

10 instruction L = saload, register 0 is guaranteed to contain a reference to an object of class C. 

1 1 The various types which are manipulated during the verification and stored in the table of 

12 register iype stype array and in the type stack are represented in fi gFig . 3b. These types include: 

13 • class identifiers CB corresponding to specific object classes which are defined in the 

14 applet; 

15 • basebasic types, such as short^-an integer coded on p = 16 bits, iatlintl and int2, the 

16 most and least significant p bits respectively of integers coded on, e.g., 2p bits, or retaddr, the 

1 7 return address of an instruction as mentioned above; 

18 • the type null, representing the references of null objects. 

19 Regarding the subtyping relation, it is indicated that a type Tl is a subtype of a type T2 if 

20 e v e ry any valid value of type Tl is also a valid value of type T2. The subtyping between class 

21 identifier reflects the inheritance hierarchy between classes of the applet. On the other types, 

22 subtyping is defined by the lattice shown in fig. 3b, where !_ is a subtype of all the types and all_ 

23 the types are subtypes of T. 
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1 The sequence of the process of verifying a subpro gram subroutine which forms an applet 

2 is as follows, referring to the abovementioned tab karray Tl . 

3 The verification process is carried out independently on each subpro gram subroutine of 

4 the applet. For each subprogram subroutine . the process carries out one or more verification 

5 passes on the instructions of the relevant subprogram, subroutine. The pseudocode of the 

6 verification process is given in tebl earray T2 in the annex. 

7 The process of verifying a subpro gram subroutine begins with initializing the type stack 

8 and the tabl e of register type stype array shown in tabl earray Tl, this initialization reflecting the 

9 state of the virtual machine at the start of execution of the subpro gra m subroutine being 

10 examined. 

1 1 The type stack is initially empty, the stack pointer equals zero, and the register types are 

12 initialized with the types of the parameters of the subprogra m subroutine . illustrating the fact that 

13 the virtual machine passes the parameters of this subpro gram subroutine in these registers. The 

14 register types which ar e allocated by the subpro gra m subroutine are initialized to data types JL, 

15 illustrating the fact that the virtual machine initializes these registers to zero at the start of 

1 6 execution of the subprogra m subroutine . 

17 Next, one or more verification passes on the instructions and on each current instruction Ii 

18 of the subpro gra m subroutine are carried out. 

19 At the end of the implemented verification pass, or of a succession of passes for 

20 instanc e example . the verification process determines whether the register types contained in the 

21 tabl e of register typ e s shown in tabl etype array represented in array Tl of the annex have changed 

22 during the verification pass. In the absence of change, verification is terminated and a success 
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1 code is returned to the main program, which makes it possible to send the positive reception 

2 acknowledgment at stage step 105 of the management protocol process shown in 6 gFig . 2. 

3 If a change to the abovementioned tabl e of register type stype array is present, the 

4 verification process repeats the verification pass until the register types contained in the tabl e of 

5 register tvpefr4stvpe array are stable. 

6 The sequence proper of a verification pass which is carried out one or more times until 

7 the tabl e of register type stype array is stable will now be described with reference to flg sFigs . 3c 

8 to 3j. 

9 For each current instruction L, the following verifications are carried out: 

10 With reference to 6gFi g . 3 a at stag estep 201, the verification process determines whether 

1 1 the current instruction L is the target of a branching branch instruction, a subroutine call or an 

12 exception-handler call, as mentioned above. This verification is carried out by examining the 

13 branching branch instructions in the code of the subprogra m subroutine and the- exception 

1 4 handlers associated with this subprogram subroutine . 

15 With reference to fl gFig . 3c which begins with stagestep 201, when the current 

16 instruction L is the target of a branchin g branch instruction, this condition being implemented by a 

17 test 300 designated by L = CIB, this branchin g branch being unconditional or conditional, the 

18 verification process checks that the type stack is empty at this point of the subprogram subroutine 

19 by a test 301. On a positive response to the test 301, the verification process is continued by a 

20 context continuation stagestep marked continue A. On a negative response to the test 301, the 

21 type stack not being empty, the verification fails and the applet is rejected. This failure is 

22 represented by the Failure stagestep. 
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1 With reference to fi gFig . 3d which begins with the continue A stagesteg, when the current 

2 instruction L is the target of a subroutine call, this condition being implemented by a test 304 L = 

3 CSR, the verification process verifies, in a test 305, that the previous instruction h -i does not 

4 continue in sequence. This verification is implemented by a test stagestep 305 when the previous 

5 instruction is an unconditional branchin gb ranch , a subroutine return or a faism gwithdrawal of an 

6 exception. The test at stagestep 305 is marked as follows: 

7 Ii-i = IBunconditkmai, return RSR or raisin gwithdrawal L-EXCEPT. 

8 On a negative response to test 305, the verification process fails in a Failure stagestep. 

9 On the other hand, on a positive response to test 305, the verification process reinitializes the 

10 type stack 306 i n such a way that it contains exactly one entry of retaddr type, the return address 

1 1 of the abovementioned subroutine. If the current instruction Ii at stag estep 304 is not the target of 

12 a subroutine call, the verification process is continued in the context at the continue B stag estep . 

13 With reference to fi gFig . 3e, when the current instruction L is the target of an exception 

14 handler, this condition ' being implemented by a test 307 marked L = CEM, where CEM 

15 designates the target of an exception handler, this condition is implemented by a test 307, 

16 marked: 

17 Ii = CEM. 

18 On a positive response to test 307, the process verifies that the previous instruction is an 

19 unconditional branching branch, a subroutine return or a gaisift gwithdrawal of exceptions by a test 

20 305, marked: 

21 Ii-i = ^unconditional, return RSR or raisift gwithdrawal L-EXCEPT. 

22 On a positive response to test 305, the verification process proceeds to reupdate the type 

23 stack, at a stag estep 308, by e nt e rin g with an exception types entry , marked EXCEPT type, 
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1 stagestep 308 being followed by a context continuation stagestep, continue C. On a negative 

2 response to test 305, the verification process fails b ywith the stagestep marked Failure. The 

3 program fragment is then rejected. 

4 With reference to fi gFig . 3f, when the current instruction L is the target of multiple 

5 incompatible branching sb ranches . this condition is implemented by a test 309, which is marked: 

6 L = incompatible XIBs 

7 theincompatible branchings b ranches being, for instance, an unconditional branchin gb ranch and a 

8 subroutine call, or even t wo different exception handlers. On a positive response to test 309, the 

9 branching sb ranches being incompatible, the verification process fails b ywith a stagestep marked 

10 Failure and the program fragment is rejected. On a negative response to test 309, the verification 

1 1 process is continued b ywith a stagestep marked continue D. Test 309 begins with the continue C 

1 2 stag e which was stgp mentioned previously in the description. 

13 With reference to figFig. 3g, when the current instruction L is not the target of any 

14 bremching branch, this condition being implemented by a test 310 beginning with the 

1 5 abovementioned continue D, this test being marked 

16 L 3? branchin gb ranch targets, 

1 7 where 3 d e signat e s denotes the existence symbol, 

1 8 the verification process continues on a negative response to the test 3 1 0 by passin ggoing on to an 

19 update of the type stack at stagestep 311, stagestep 311 and the 1 positive response to test 310 

20 being followed by a context continuation stag estep at stagestep 202, which is described above in 

21 the description with reference to fi gFig . 3a. 
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1 A more detailed description of the stag e o f step for verifying the effect of the current 

2 instruction on the type stack at the abovementioned stag estep 202 will now be given with 

3 reference to fi gFig . 3h. 

4 According to the abovementioned figure, this stagestep can include at least one stag estep 

5 400 of v e rificatio n for verifying that the type execution stack includ e s contains at least as many 

6 entries as the current instruction includes operands. This test stag estep 400 is marked: 

7 NbepfeNOpi 

8 where Nbep d e signat e s denotes the number o f e ntri e s of th e type stack entries and NOpi 

9 d e signat e s denotes the number of operands includ e d contained in the current instruction. 

10 On a positive response to test 400, this test is followed by a stagestep 401a effor 

1 1 unstacking the type stack, and effor verifying 401b that the types of the entries at the top of the 

12 stack are subtypes of the types of the operands of the abovementioned current instruction. At test 

13 stag estep 401a, the operand types of the instruction i are marked TOpi, and the types of the 

14 entries at the top of the stack are marked Targs. 

15 At stagestep 401b, the verification corresponds to a verification of the subtyping relation 

16 Targs subtype of TOpi. 

17 On a negative response to tests 400 and 401b, the verification process fails, which is 

18 shown by access to the Failure stagestep. On the other hand, on a positive response to test 401b, 

19 the verification process is continued, and consists in carrying out: 

20 • —A stag e o f step for verifying the existence of a sufficient memory space on the type 

21 stack to proceed to stack the results of the current instruction. This verification stagestep is 

22 implemented by a test 402, marked: 

23 Stack-space > Results-space 
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1 where each side of the inequality d e signat e s denotes the corresponding memory space. 

2 On a negative response to test 402, the verification process fails, which is shown by the 

3 Failure stagestep. On the other hand, on a positive response to test 402, the verification process 

4 then proceeds to stack the data types which ar e assigned to the results in a stag estep 403, the 

5 stacking being done on the stack of data types which ar estack assigned to these results. 

6 As a nonlimiting example, it is indicated that to implement fi gFig . 3h for verifying the 

7 effect of the current instruction on the type stack, for a current instruction consisting of a 

8 Jav aJAVA saload instruction corresponding to reading an integer element coded on p = 16 bits in 

9 a tabl e of int e gers an integer array , this tabl e of int e ger s integer array being defined by the tabl e of 

10 intogeF sinteger array and an integer index in this taWearray, and the result by the integer which is 

1 1 read at this index in this tab tearray . the verification process checks that the type stack contains at 

12 least two elements, that the two elements at the top of the type stack are subtypes of short [ ] and 

13 short respectively, proceeds to the unstacking process and then to the process of stacking the data 

14 type short as the result type. 

15 Additionally, with reference to figEig. 3i, to implement the stag e o f step for verifying the 

16 effect of the current instruction on the type stack, when the current instruction h is a read 

17 instruction, marked IR, of a register of address n, this condition being implemented by a test 404 

18 marked L = IR n , on a positive response to the abovementioned test 404, the verification process 

19 consists in verifying the data type of the result of this feadingread, in a stagestep 405, by reading 

20 the entry n in the tabl e of register fepe stype array , then in determining the effect of the current 

21 instruction Ii on the type stack by an operation 406a of unstacking the entries of the stack 

22 corresponding to the operands of this current instruction and by stacking 406b the data type of 

23 this result. The operands of the instruction h are marked OPi. Stag e s_ Steps 406a and 406b are 
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1 followed by a return to the context continuation, continue F. On a negative response to test 404, 

2 the verification process As continued by the context continuation, continue F. 

3 With reference to fi gFig . 3j, when the current instruction L is a write instruction, marked 

4 IW, of a register of address n, this condition being implemented by a test marked L = IW m , on a 

5 positive response to test 407, the verification process consists in determining, in a stagestej) 408, 

6 the effect of the current instruction on the type stack and the type t of the operand which is 

7 written in the register of address n, then, in a stagestep 409, in replacing the type entry of the 

8 tabl e of register type stype array at address n b ywith the type immediately above the previously 

9 stored type and above the type t of the operand which is written in the register of address n. 

10 Stag eStep 409 is followed by a return to the context continuation, continue 204. On a negative 

1 1 response to test 407, the verification process is continued by a context continuation, continue 

12 204. 

13 As an example, when the current instruction h corresponds to writing a value of type D 

14 into a register of address 1, and the type of register 1 before verification of the instruction was C, 

15 the type of register 1 is replaced by the type object, which is the smallest type which is higher 

16 than C and D in the lattice of types shown in fi gFig . 3b. 

1 7 In the same way, as an example, when the current instruction L is a read of an instruction 

1 8 aload-0 consisting in stacking the cont e nts content of register 0, and entry 0 of the tabl e of register 

19 tvpestvpe array is C, the verifier stacks C onto the type stack. 

20 An example of verifying a subpro gram subroutine written in a Jav aJAVA environment 

21 will now be given, with reference to tables T3 and T4 in the annex. 

22 Tabl e Array T3 represents a specific JavaCard JAVACARD code corresponding to the 

23 Java subprogram which is subroutine included in this tab tearray . 
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1 tabl e Array T4 shows the cont e nts content of the tabl e of register type stype array and of the 

2 type stack before verification of each instruction. The type constraints on the operands of the 

3 various instructions are all observed. The stack is empty both after the instruction 5 to branch to 

4 instruction 9, symbolized by the arrow, and before the abovementioned branchin gb ranch target 9. 

5 The type of register 1, which was initially _L, becomes null, the upper bound of null and ±, when 

6 instruction 1 to store a value of type null in register 1 is examined, then becomes of type short [ ], 

7 the upper bound of types short[ ] and null, when instruction 8 to store a value of type short [ ] in 

8 register 1 is processed.— ¥h e Since the type of register 1 having has changed during the first 

9 verification pass, a second pass is carried out, distributin g this time starting from the register 

10 types which w e re obtained at the end of the first. This second verification pass is successful, just 

1 1 like the first, and does not change the register types. The verification process thus terminates 

12 successfully. 

13 Various examples of cases of failure of the verification process on four examples of 

14 incorrect code will now be given with reference to tabl earray T5 in the annex: 

15 • At point a) of tabi earray T5, the purpose of the code given as an example is to attempt 

16 to fabricat econstruct an invalid object reference using an arithmetic process on pointers. It is 

17 rejected by verification of the types of arguments of instruction 2 sadd, which requires these two 

1 8 arguments to be of type short. 

19 • At points b) and c) of tabl earray T5, the purpose of the code is to carry out two 

20 attempts to transfor m convert any integer into an object reference. At point b) , register 0 is used 

21 simultaneously with type short, instruction 0, and with type null, instruction 5. Consequently, the 

22 verification process assigns type T to fe6erdregister 0, and detects a type error when register 0 is 

23 returned as a result of type object at instruction 7. 
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1 • At point c) of tablearray T5, a set of branching s branches of type "if . . . then . . . else . 

2 . " is used to leave at the top of the stack a result which consists of either an integer or an object 

3 reference. The verification process rejects this code because it detects that the stack is not empty 

4 at the branchin g branch from instruction 5 to instruction 9, symbolized by the arrow. 

5 • Finally, at point d) of tabtearray 5, the code contains a loop which, aton each iteration, 

6 has the effect of stacking an additional integer on the top of the stack, and thus causing a stack 

7 overflow after a certain number of iterations. The verification process rejects this code, 

8 noticin g observing that the stack is not empty at the backward branchin gb ranch from instruction 8 

9 to instruction 0, symbolized by the return arrow, the stack not being empty at a branchin gb ranch 

10 point. 

11 The various examples given above with reference to tables T3, T4 and T5 show that the 

12 verification process, which is the subject of the present invention, is particularly 

13 e ffioi e n t effective . and that it applies to applets, and in particular to subprograms subroutines 

14 thereof, for which the conditions of stack type, or respectively of the empty character of the type 

15 stack* previousl y, and to_ on the branchin gb ranch or branch target instructions or branching 

16 targ e ts , are satisfied. 

17 Obviously, such a verification process implies writing object codes which satisfy these 

18 criteria, these object codes possibly corresponding to the sub progra m subroutine in the 

1 9 abovementioned tabl earray T3 . 

20 However, and in order to ensure the v erification of existing applets and 

21 subprograms subroutines of applets which do not necessarily satisfy the verification criteria of the 

22 method which is the subject of the present invention, in particular regarding applets and 

23 subprograms which ar e subroutines written in the Java environment, the purpose of the present 
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1 invention is to establish methods of transforming these applets or subprograms subroutines into 

2 standardized applets or program fragments , making it possibl e to undergo that can successfully 

3 undergo t he verification tests of the verification method which is the subject of the present 

4 invention and of the management protocol process which implements such a method. 

5 For this purpose, the subject of the invention is the implementation of a method and a 

6 program for transforming a traditional eonventional object code forming an applet, it being 

7 possible to implement this method and this transformation program^ outside an en- 

8 beaf dembedded system or microprocessor card 7 when the relevant applet is created. 

9 The method of transforming code into standardized code, which is the subject of the 

10 present invention, will now be described in the framework of the Jav aJAVA environment, as a 

1 1 purely illustrative example. 

12 The JVM codes which are p roduced by existing Jav aJAVA compilers satisfy various 

1 3 criteria, which are stated below: 

14 €1C1: the arguments of each instruction actually do belong to the types which this 

1 5 instruction expects; 

16 C2 : the stack does not overflow; 

17 C'3: for each branchin g branch instruction, the type of the stack at this branching branch 

1 8 is the same as at the possible targets for this branchingi b ranch: 

19 C'4: a value of type t which is written into a register at one point of the code and 

20 ferea dread back from the same register at another point of the code is always 

21 ferea dread back with the same type t; 
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1 The implementation of the verification method which is the subject of the present 

2 invention impli e s tha t entails criteria C'3 and CM, which ar e verified by the object code which is 

3 submitted for verification, b ebeing replaced by criteria C3 and C4 below: 

4 C3: the stack is empty at each branchin g branch instruction and at each 

5 branching branch target; 

6 C4: the same register is used with one and the same type throughout the code of a 

7 subprogram, subroutine. 

8 With reference to the abovementioned criteria, it is indicated that Java compilers 

9 guarantee only the weaker criteria C'3 and C'4. The verification process which is the subject of 

10 the present invention and the corresponding management protocol process in fact guarantee more 

11 restrictive criteria C3 and C4, making it possible to ensure the security of execution and 

1 2 management of applets. 

13 The concept of standardization, covering the transformation of codes into standardized 

14 codes, can present various aspects, teinasmuch as the e xt e nt that replacement of criteria C'3 and 

15 C'4 by criteria C3 and C4, in conformit y accordance with the verification process which is the 

16 subject of the present invention, can be implemented ind e p e nd e ntl y separately . to ensure that the 

17 stack is empty at each branchin g branch instruction and at each branchin g branch target, and 

18 respectively that the registers which the applet opens are typed, and a single data type which is 

19 assigned for execution of the relevant applet corresponds to each open register, or, on the other 

20 hand, jointly, to satisfy the whole of the verification process which is the subject of the present 

21 invention. 

22 The method of transforming an object code into standardized object code as claim e d 

23 i naccording to the invention will consequently be described as claim e d i n according to two 
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1 distinct impl e m e ntation — mode sembodiments . a first impl e m e ntation — med eembodiment 

2 corresponding to the transformation of an object code which satisfies criteria CI, C2, C'3, C'4 

3 into a standardized object code which satisfies criteria GhCh C2, C3, C'4 corresponding to a 

4 standardized code with an empty branchin g branch instruction or branchin gb ranch target, then, as- 

5 claim e d — i naccording to a second impl e m e ntation — med eembodiment , in which the 

6 traditional conventional object code which satisfies the same initial criteria is transformed into a 

7 standardized object code which satisfies criteria CI, C2, C'3, C4, for instance corresponding to a 

8 standardized code using typed registers. 

9 The first impl e m e ntation mod eembodiment of the code transformation method which is 

10 the subject of the present invention will now be described with reference to figEig. 4a. In the 

11 impl e m e ntation — mod e — which — i sembodiment shown in 6 gFig . 4a, the initial 

12 traditional conventional code is considered to satisfy criteria C1+C2+C3, and the standardized 

13 code which is . obtained as the result of the transformation is considered to satisfy criteria 

14 C1+C2+C3. ♦ 

15 According to the abovementioned figure, the transformation method consists, for each 

16 current instruction L of the code or of the subprogra m subroutine , in annotating each instruction, 

17 in a stagestep 500, with the data type of the stack before and after execution of this instruction. 

18 The annotation data is marked Ah and is associated by the relation l\ <-> <->AL_ with in the 

19 relevant current instruction. The annotation data is calculated by means of an analysis of the data 

20 stream relating to this instruction. The data types before and after execution of the instruction are 

21 marked tbei and tae* respectively. Calculation of annotation rdata by analysis of the data stream is 

22 a traditional conventional calculation which is known to those skilled in the art, and will therefore 

23 not be described in detail. 
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1 The operation which is impl e m e nt e d carried out at stag estep 500 is illustrated in tabl earray 

2 T6 in the annex, in which, for an applet or subprogram of an apple t subroutine including 12 

3 instructions, the annotation data AL made up of the types of registers and the types of the stack 

4 afeis introduced. 

5 The abovementioned stagestep 500 is then followed by a stag estep 500a consisting in 

6 positioning the index i on the first instruction Ii = Stag eli. Step 500a is followed by a stagestep 

7 501 consisting in detecting, among the instructions and in each current instruction L, the 

8 existence of branchings branches marked IB or of branchin g branch targets CIB for which the 

9 execution stack is not empty. This detection 501 is implemented by a test which is carried out on 

10 the basis of the annotation data AL of the type of stack variables allocated to each current 

1 1 instruction, the test being marked for the current instruction: 

12 Ii is an IB or CIB and stack (AI) empty. 

13 On a positive response to test 501, i.e. in the presence of detection of a non-empty 

14 execution stack, the abovementioned test is followed by a stagestep consisting in inserting 

15 instructions to transfer stack variables on either side of these branchings b ranches IB or 

16 branching branch targets CIB, in order to empty the content of the execution stack into temporary 

17 registers before this branchin g branch and to reestablish the execution stack from the temporary 

18 registers after this branching. b ranch. The insertion stagestep is marked 502 in SgEig. 4a. It is 

19 followed by a stagestep 503 to test the reaching of the last instruction, marked 

20 Ii = last instruction? 

21 On a negative response to the-test 503, an increment 504 i=i+l is carried out, to go on to the next 

22 instruction and return to stag estep 501. On a positive response to test 503, an End stagestep is 

23 initiated. On a negative response to test 501, the transformation method is continued by a 
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1 branchin gb ranch to stag estep 503 in the absence of insertion of a transfer instruction. — 

2 Impl e m e ntatio n The implementation of the method of transforming a traditional conventional 

3 code into a standardized code with branchin g branch instruction with empty stack as represented 

4 in fi gFig . 4a makes it possible to obtain a standardized object code for the same initial program 

5 fragment in which the stack of stack variables is empty at each branching branch instruction and 

6 each branching b ranch target instruction, in the absence of any modification to the execution of 

7 the program fragment. In the case of a Java environment, the instructions to transfer data 

8 between stack and register are the load and store instructions of the Java virtual machine. 

9 Returning to the example introduced in tabl earray T6, the transformation method detects 

10 a branchin g branch target where the stack is not empty at instruction 9. Th e m e thod is th e n to 

1 1 ins e rt a n An instruction istore 1 is then inserted before the branchin gb ranch instruction 5 which 

12 leads to the abov e m e ntion e d abovementioned instruction 9, in order to save the content of the 

13 stack in register 1 and ensure that the stack is empty at the time of the branching, b ranch, 

14 Symmetrically, an instruction iload 1 is inserted before the instruction target 9, to reestablish the 

15 content of the stack exactly as it was before the branching, b ranch. Finally, an instruction istore 1 

16 is inserted after instruction 8 to ensure that the stack is balanced on the two paths which lead to 

17 instruction 9. The result of the transformation carried out in this way into a standardized code is 

1 8 shown in tebl earray T7 . 

19 The second impl e m e ntation mode embodiment of the transformation method which is the 

20 subject of the present invention will now be described with reference to fi gFig . 4b in the case in 

21 which the initial traditional conventional object code satisfies criteria GiCl+C'4 and the 

22 standardized object code satisfies criteria C1+C4. 



#4597691 vl 



1 With reference to the abovementioned figEig. 4b, it is indicated that the method, in this 

2 impl e m e ntation mod eembodiment consists in annotating, as claim e d in a stag eaccording to a 

3 step 500 which is approximately the same as that which is shown in SgFig. 4a, each current 

4 instruction h with the data t ype of r e gist e r dat a the registers before and after execution of this 

5 instruction. In the same way, the annotation data AliAIi is calculated by means of an analysis of 

6 the data stream relating to this instruction. 

7 The annotation stagestep 500 is then followed by a stag estep consisting in carrying out a 

8 reallocation of the registers, the stegestep marked 601, by detecting the original registers 

9 employed with different types, byand dividing these original registers into separate standardized 

10 registers, one standardized register being allocated to each data type used.— Stag e Step 601 is 

1 1 followed by a stagestgp 602 effor reupdating the instructions which manipulate the operands 

12 which use the abovementioned standardized registers. StageStep 602 is followed by a context 

1 3 continuation stagestep 302. 

14 With reference to the example given in tablearray T6, it is indicated that the 

15 transformation method detects that the register of rank 0, marked rQ rrO. is used with the two 

16 types, object, instructions 0 and 1, and int, instruction 9 and following. The m e thod is th e n to 

17 divid e th e original register fQrO is then divided into two registers, register 0 for the use of object 

18 types and register 1 for uses of int type. References to feeef dregister 0 of int type are then 

1 9 rewritten by transforming them into references to feeef dregister 1 , the standardized code obtained 

20 being shown in tabiearray T8 in the annex. 

21 It is noted, in a nonlimiting way, that in the example which is introduced with reference 

22 to the abovementioned tabl earray T8, the new register 1 is used simultaneously for 
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1 standardization of the stack and for the creation of typed registers by dividing of register 0 into 

2 two registers. 

3 The method of transforming a traditional conventional code into a standardized code with 

4 branching branch instruction with empty stack as described in fi gFig . 4a will now be described in 

5 more detail in a preferred, nonlimiting impl e m e ntation mod oembodiment . in relation to fl gFig . 

6 5a. 

7 This impl e m e ntation mod e embodiment concerns stagestep 501, consisting in detecting, 

8 within the instructions and within each current instruction l h the existence of branchin gb ranch 

9 IB, or respectively of branchin gb ranch target CIB, for which the stack is not empty. 

10 Following the determination of target instructions where the stack is not empty, this 

1 1 condition being marked at stagestep 504a, L stack^empty, the transformation process consists 

12 in associating with these instructions, at the abovementioned stagestep 504a, a set of new 

13 registers, one pe rfor each stack location which is active at these instructions. Thus, if i 

14 d e signat e s denotes the rank of a branchin gb ranch target of which the associated stack type is not 

15 empty and is of type tp ktpli to tpnj with n > 0, stack not empty, the transformation process 

16 allocates n new, as yet unused, registers, f£l to r n , and associates them with the corresponding 

17 instruction i. This operation is implemented at stag estep 504a. 

18 StageStep 504a is followed by a stagestep 504 consisting in examining each detected 

19 instruction of rank i and identifying, in a test stag estep 504, the existence of a branching branch 

20 target CIB or of a branching branch IB.— Stag e Step 504 is shown in the form of a test designated 

21 by: 

22 £3? CIB, IB and L= CIB. 
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1 In the case tha twhere the instruction of rank i is a branchin g branch target CIB represented 

2 by the preceding equality, and thatwhere the stack of stack variables at this instruction is not 

3 empty, i.e. with a positive response to test 504, for evervany preceding instruction of rank i-1 

4 consisting of a branchin g branch . a gaisift gwithdrawal of an exception or a program return, this 

5 condition is implemented at test stagestep 505, designated by: 

6 Ii-i = IB, EXCEPT faisffl gwithdrawak Prog, return. 

7 The detected instruction of rank i is only accessible by a branching, branch. On a positive 

8 response to the abovementioned test 505, the transformation process consists in carrying out a 

9 stagestep 506 consisting in inserting a set of load instructions of load type from the set of new 

10 registers before the relevant detected instruction of rank i. The insertion operation 506 is 

1 1 followed by a redirection 507 of all branchings branches to the detected instruction of rank i, to 

12 the first inserted load instruction load. The insertion and redirection operations are shown in 

1 3 tabi earray T9 in the annex. 

14 For evetyany preceding instruction of rank i-1 continuing in sequence, i.e. when the 

15 current instruction of rank i is accessible simultaneously by a branching branch and from the 

16 preceding instruction, this condition being implemented by test 508 and symbolized by the 

17 relations: 

18 Ii-i->Ii 

19 And 

20 and 

21 IB->Ii 

22 the transformation process consists,, in a stag e 509 o f step 509. in inserting a set of baeka pstore 

23 instructions stor e to back up save to the set of new registers before the detected instruction of rank 
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1 i, and a set of load instructions-lead to load from this set of new registers.^tag e Step 509 is then 

2 followed by a stagestep 510 of r e dir e ction o f for redirecting all the branchings branches to the 

3 detected instruction of rank i to the first inserted load instruction -lead . 

4 In the case thatwhere the detected instruction of rank i is a branchin g branch to a 

5 determined instruction, for any detected instruction of rank i consisting of an unconditional 

6 branchin g branch , this condition being implemented by a test 511 marked: 

7 Ii — 1 — = IBuncondit. 

8 the transformation process as shown in fi gFig . 5a consists in inserting at a stagestep 512, on a 

9 positive response to test 511, before the detected instruction of rank i, multiple baeka pstore 

10 instructions-store. The transformation process inserts before the instruction i the n store 

1 1 instructions stor e as shown in tabl earray Til as an example. The store i nstructions -store address 

12 registers rai to r n , where n designat e s denotes the number of registers. Thus the baeku pstore 

13 instruction is associated with each new register. 

14 For every detected instruction of rank i consisting of a conditional branching branch, and 

15 for a number mOp, greater than 0, of operands manipulated by this- conditional branchin gb ranch 

1 6 instruction, this condition being implemented by the test 5 1 3 marked: 

1 7 Ii-^--=IB C ondit. 

18 withmOp>0 

19 the transformation process, mon a positive response to the abovementioned test 513, consists of 

20 inserting, at a stag estep 514 before this detected instruction of rank i, a p e rmutati e nswap 

21 instruction marked swap_x at the top of the stack of stack variables of the mOp operands of the 

22 detected instruction of rank i and the n following values. This p e rmutatio n swap operation makes 

23 it possible to collect at the top of the stack of stack variables the n values to be back e d up stored 
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1 in the set of new registers *&! to r n . Steg eStep 514 is followed by a stag estep 515 consisting in 

2 inserting, before the instruction of rank i, a set of baeka pstore instructions stor e to back up save to 

3 the set of new registers rai to r n . The abovementioned insertion stagestep 515 is itself followed 

4 by a stegestep 516 effor insertion, after the detected instruction of rank i, of a set of load 

5 instructions load to load from the set of new registers f£i to r n . The set of corresponding 

6 insertion operations is shown in taWearray 12 in the annex. 

7 For reasons of completeness and with reference to figFig. 5a, it is indicated that, on a 

8 negative response to test 504, the continuation of the transformation process is implemented by a 

9 context continuation stagestep, continue 503, that the negative response to tests 505, 508, 511 

10 and 513 is itself followed by a continuation of the transformation process via a context 

1 1 continuation stagestep, continue 503, and that the same applies to the continuation of operations 

12 after the abovementioned redirection stagessteps 507 and 510 and insertion stagessteps 512 and 

13 516. 

14 A more detailed description of the method of standardizing and transforming an object 

15 code into a standardized object code using typed registers as described in figFig. 4b will now be 

16 given with reference to fi gFig . 5b. This impl e m e ntation mod eembodiment concerns, more 

17 particularly, a nonlimiting, preferred impl e m e ntation mod e of stag e embodiment of step 601 te- 

18 r e allocat efor reallocating the registers by detecting the ^original registers used with different 

19 types. 

20 With reference to the abovementioned flgFig. 5b, it is indicated that the abovementioned 

21 stegestep 601 consists in determining, in a stagest^ 603, the lifetime intervals marked IDj of 

22 each register These lifetime intervals, designat e d called "live range" or "wefa" are defined 

23 for a register r as a maximum set of partial traces such that register r is live at all points of these 
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1 traces. For a more detailed definition of these concepts, it is useful to refer to the work edited by 

2 Steven S. MUCHNICK entitled "Advanced Compiler Design and Implementation", Section 16.3, 

3 Morgan KAUFMANN, 1 997.-Stage_Step 603 is designated by the relation: 

4 IDj <-> i — >rj 

5 as claim e d in according to which a corresponding lifetime interval IDj is associated with each 

6 register rj. 

7 The abovementioned stagestep 603 is followed by a stagestep 604 consisting in 

8 determining, at stag estep 604, the main data type, marked tpj, of each lifetime interval IDj. The 

9 main type of a lifetime interval IDj, for a register rj, is defined by the upper bound of the data 

10 types stored in this register rj by the baeku pstore instructions store— belonging to the 

1 1 abovementioned lifetime interval. 

12 StageStep 604 is itself followed by a stagestep 605 consisting in establishing an 

13 interference graph between the lifetime intervals as defined above at stage ssteps 603 and 604, 

14 this interference graph consisting of a non-oriented graph of which each peak consists of a 

15 lifetime interval, and of which the arcs, marked aji, j2 on fi gFig . 5b, between two peaks JDjilDp. 

16 and IDj2, exist if a peak contains a baeku pstore instruction addressed to the register of the other 

17 peak or vice versa. In fi gFig . 5b, the construction of the interference graph is shown 

18 symbolically, it being possible to implement this construction on the basis of calculation 

19 techniques which ar e known to those skilled in the art. For a more detailed description of the 

20 construction of this type of graph, it is useful to refer to the work published by Alfred V. AHO, 

21 Ravi SETHI and Jeffrey D. ULLMAN entitled "Compilers: principles, techniques, and tools", 

22 Addison- Wesley 1 986, Section 9.7. 



#4597691 vl 



42 



1 Following stag estep 605, the standardization method as shown in fig. 5b consists in 

2 translating, in a stag estep 606, the uniqueness of a data type which is allocated to each register rj 

3 in the interference graph, by adding arcs between all pairs of peaks of the interference graph 

4 while two peaks of a pair of peaks do not have the same associated main data type. It is 

5 understood that the translation of the uniqueness character of uniqu e n e ss of a data type which is 

6 allocated to each register obviously corresponds to translating and taking into account the 

7 translation and recognition criterion C4 in the interference graph, this criterion being mentioned 

8 previously in the description. The abovementioned stagestep 606 is then followed by a stagestep 

9 607 in which an instantiation of the interference graph is carried out, this instantiation being 

10 more commonly d e signat e d known as the painting stag ecoloring step of the interference graph as- 

1 1 claim e d i n according to the usual techniques. During stagestep 607, the transformation process 

12 assigns to each lifetime interval IDjk a register number rk, in such a way that two adjacent 

13 intervals in the interference graph receive different register numbers. 

14 This operation can be implemented on the basis of any suitable process. As a nonlimiting 

15 example, it is indicated that a- preferred process can consist: 

16 a) in choosing a peak of minimum degree in the interference graph, minimum degree 

17 being defined as a minimum number of adjacent peaks, and with- 

1 8 drawin g removing it from the graph. This stagestep can be repeated until the graph 

19 is empty. 

20 b) Each previously withdraw nr emoved peak is reintroduced into the interference 

21 graph in the iftveFs ereverse order of their withdrawal removah the last to be 

22 removed being the first to be reintroduced, and successively in the inversereverse 

23 order of the order of withdrawal, removal. Thus the smallest register number 
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1 which is different from the numbers assigned to all the adjacent peaks can be 

2 assigned to each reintroduced peak. 

3 Finally, by steg estep 602, shown in figFig. 4b, the transformation and reallocation process 

4 rewrites the register access instructions to th e r e gist e rs in the code of the subprogra m subroutine 

5 of the relevant applet. Access to a given register in the corresponding lifetime interval is 

6 replaced by access to a different register, the number of which has been assigned during the 

7 instantiation phase, also designated the paintin g coloring phase. 

8 A more detailed description of an on boar d embedded data-processing system , making it 

9 possibl e to impl e m e nt for implementing the management protocol process and verification 

10 process of a program fragment or applet as claim e d i n accordance with the subject of the present 

1 1 invention, and of a development system of an applet, will now be given with reference to fl gFig . 

12 6. 

13 Regarding the corresponding on board embedded system with reference 10, it is recalled 

14 that this on boar d embedded system is a reprogrammable-type system, including the essential 

15 components as shown in fl gFig . lb. The abovementioned on boar d embedded system is 

16 considered to be interconnected to a terminal by a serial link, the terminal itself being linked, for 

17 instance via a local area network, if appropriate a feme tewide area network, to an applet 

18 development computer with reference 20. On the on boar d embedded system 10 runs lO. a main 

19 program runs which reads and executes the commands whie hsent by the terminal sends on over 

20 the serial link. Additionally, the standard commands for a microprocessor card, such as for 

21 instance the standard commands of the ISO 7816 protocol, can be implemented, aad-the main 

22 program r e cogniz e s recognizing two additional commands, one for r e mot e — loading 
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1 e filownloading an applet, and the other for selecting an applet which has previously been loaded 

2 onto the microprocessor card. 

3 In conformit y accordance with the subject of the present invention, the structure of the 

4 main program is implemented in such a way as to include at least one program module for 

5 management and verification of a downloaded program fragmen t, followin g according to the 

6 protocol process for managing a downloaded program fragment as described above in the 

7 description with reference to fi gFig . 2. 

8 Additionally, the program module also includes a subpro gra m subroutine module to verify 

9 a downloaded program fragment , followin g according to the verification method as described 

10 above in the description with reference to fig sFigs . 3a to 3j. 

1 1 For this purpose, the structure of the memories, in particular the non- writable permanent 

12 memory ROM, is modified in such a way as to include in particular, apart from in addition to the 

13 main program, a protocol process management and verification module 4-7 rl7 and a virtual 

14 machine 16 for interpreting the software code, as mentioned above. Finally, regarding the 

15 nonvolatile rewritable memory of EEPROM type, this advantageously includes a directory of 

16 applets, marked 18, making it possibl e to impl e mon t for implementing the management 

17 protocol process and the verification process which are the subjects of the present invention. 

18 With reference to the same SgFig. 6, it is indicated that the applet development system 

19 conforming to the subject of the present invention, in fact making it possibl e to transform a 

20 traditional for transforming a conventional object code as mentioned above in the description, and 

21 satisfying criteria Cl+C2+C4413+C'4 in the framework of the Java environment, into a 

22 standardized object code for the same program fragment, includes, associated with a 

23 traditional conventional Java compiler 21, a code transformation module, marked 22, which 
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1 proceeds to transform code into standardized code as claim e d i n according to the first and second 

2 impl e m e ntation modes embodiments described above in the description with reference to flg sFig 

3 s. 4a, 4b and 5a, 5b. It is in fact understood that, on the one hand, standardization of the original 

4 object code into a standardized object code with branchin g branch instruction with empty stack 

5 and into a standardized code using typed registers, on the other hand, as mentioned previously in 

6 the description, makes it possible to satisfy verification criteria C3 and C M, which ar e l imposed 

7 by the verification method which is the subject of the present invention. 

8 The code transformation module 22 is followed by a JavaCard transform e r JAVACARD 

9 converter 23, which makes it possible to e nsur e transmission by a r e mot etransmit via a wide area 

10 or local area n etwork to the terminal and, via the serial link, to the microprocessor card 10. Thus 

11 the applet development system 20 shown in fig. 6 mak e s it possibl eis used to transform the 

12 compiled class files produced by the Java compiler 21 from the JavaJAVA source codes of the 

13 applet into class files which are equivalent, but which observe the additional constraints C3, C4 

14 which ar e imposed by the management protocol process and the verification module 1 7 embedded 

15 on board the microprocessor card 10. These transformed class files are transform e d converted 

1 6 into a. downloadabl ean applet e nwhich can be downloaded to the card by the standard JavaCard 

17 transforme r JAVACARD converter 23. 

18 Various particularly noteworthy components of the set of protocol process components, 

19 methods and systems which are the subjects of the present invention will now be given for 

20 information only. 

21 Compared to the verification processes of the prior art as mentioned in the introduction to 

22 the description, the verification method which is the subject of the present invention appears 

23 noteworthy in that it concentrates the verification effort on the typing properties of the operands 
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1 which are essential to the security of execution of each applet, i.e. observing the type constraints 

2 associated with each instruction and absence of stack overflow. Other verifications do not appear 

3 to be essential in terms of security, in particular verification that the code correctly initializes 

4 every register before reading it for the first time. On the contrary, the verification method which 

5 is the subject of the present invention operates by initializing to zero all the registers from the 

6 virtual machine when the method is initialized, to guarantee that reading a non-initialized register 

7 cannot compromise the security of the card. 

8 Additionally, the d e man d requirement imposed by the verification method which is the 

9 subject of the present invention, as claimed i n according to which the stack must be empty at each 

10 branching branch or branchin gb ranch target instruction, guarant ee s ensures that the stack is in the 

1 1 same state, empty, after execution of the branchin gb ranch and before execution of the instruction 

12 to which the program has branched. This mod e of op e ration guarant ee s procedure ensures that 

13 the stack is in a consistent state, whatever the execution reut epath which is followed through the 

14 code of the relevant subpro gra m subroutine or applet. The consistency of the stack is thus 

15 guaranteed even in the presence of a branchin gb ranch or branchin gb ranch target. Contrary to the 

16 methods and systems of the prior art, in which it is necessary to cons e rv e retain in random-access 

17 memory the type of the stack at each branching branch target, which necessitates a quantity of 

18 random-access memory proportional to TpxNb, the product of the maximum size of execution 

19 stack which is used and the number of branchin gb ranch targets in the code, the verification 

20 method which is the subject of the present invention only needs the type of the execution stack at 

21 the time of the instruction during verification, and it does not keep in memory the type of this 

22 stack at other points of the code. Consequently, the method which is the subject of the invention 
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1 is satisfied with a quantity of random-access memory proportional to Tp but independent of Nb, 

2 and consequently of the length of the code of the subpro gram subroutine or applet. 

3 The requirement as claim e d i n according to criterion C4, as claim e d in according to which 

4 a given register must be used with one and the same type throughout the code of a subprogram, 

5 guarante e s subroutine. ensures that the abovementioned code does not use a register in an 

6 inconsistent way, e.g. by writing a short integer to it at one point of the program and rereading it 

7 as an object reference at another point of the program. 

8 In the verification processes which ar e described in the prior art, in particular in the 

9 previously mentioned Java specification entitled 'The Java Virtual Machine Specification", 

10 edited by Tim LINDHOLM and Frank YELLIN, to guarantee the consistency of the 

11 abovementioned uses through the branchin g branch instructions, it is necessary to keep in 

12 random-access memory a copy of the table of register type stype array at each branchin g branch 

13 target. This operation necessitates a quantity of random-access memory proportional to T r xNb, 

1 4 where T r d e signat e s denotes the number of registers used by the subpro gra m subroutine and Nb the 

1 5 number of branching branch targets in the code of this subprogra m subroutine . 

16 On the contrary, the verification process which is the subject of the present invention 

1 7 operates on a global tabl e of register type stype array without keeping a copy at different points of 

1 8 the code in random-access memory. Consequently, the random-access memory which is required 

19 to implement the verification process is proportional to T r but independent of Nb, and 

20 consequently of the length of the code of the relevant subpro gram subroutine . 

21 The constraint as claim e d in according to which a given register is used with the same 

22 type at all points, i.e. at every instruction of the relevant code, simplifies appreciably and 

23 significantly the verification of subprograms, subroutines. On the contrary, in the verification 
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1 processes of the prior art, in the absence of such a constraint, the verification process must 

2 establish that the subprogram s subroutines observe a strict stack discipline, and must verify the 

3 body of the subprograms subroutines polymorphously regarding the type of certain registers. 

4 In conclusion, the verification process which is the subject of the present invention, 

5 compared to the techniques of the prior art, makes it possible, on the one hand, to reduce the size 

6 of the code of the p rogram cod e which mak e s it possibl e to carr y for carrying out the verification 

7 method, and on the other hand, to reduce the consumption of random-access memory during the 

8 verification operations, the degree of complexity being of the form 0(T p +P r ) in the case of the 

9 verification process which is the subject of the present invention, instead of (QO(T p +T r ) xNb) for 

10 the verification process of the prior art, while however offering the same guarantees 

1 1 abea tregarding the security of execution of the verified code. 

12 Finally, the process of transforming original traditional conventional code into 

13 standardized code is implemented by localized transformation of the code without transmitting 

14 additional information to the verifier component, i.e. the microprocessor card or en- 

1 5 beaf dembedded data-processing system. 

16 Regarding the method of reallocating registers as described in figs. 4b and 5b, this 

17 method differs from the known methods of the prior art, as described in particular in US Patents 

18 4,571,678 and 5,249,295, by the fact that: 

19 • the register reallocation ensures that the same register cannot be assigned to two 

20 intervals with different main types, which thus guarante e s ensures that a given register is used 

21 with the same type throughout the code; and 

22 • the existing register allocation algorithms, which are described in the abovementioned 

23 documents, assume a fixed number of registers, and attempt to minimize the transfers, called 
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1 "spills", between registers and stack, whereas reallocation of registers as claim e d i n accordance 

2 with the subject of the present invention operates in a framework where the total number of 

3 registers is variable, as a consequence of which there is no purpose in carrying out transfers 

4 between registers and stacks when a process of minimizing the total number of registers is 

5 carri e d out, implemented. 

6 The protocol process for managing a program fragment downloaded enteto an en- 

7 beafdembedded system, and the methods of verifying this downloaded program fragment and 

8 respectively of transforming this object code of a downloaded program fragmen t r e sp e ctively , 

9 which are the subjects of the present invention, can of course be implemented ieby software. 

10 Therefore, the present invention also concerns a computer program product which can be 

1 1 loaded directly into the internal memory of a reprogrammable on board embedded system, this 

12 on boar d embedded system making it possible to download a program fragment consisting of an 

13 object code, a series of instructions, executable by the microprocessor of the on board embedded 

14 system by wa ymeans of a virtual machine e quipp e d provided with an execution stack and with 

15 local registers or variables manipulated ¥taby these instructions 50so that this object code can be 

16 interpreted. The corresponding computer program product includes portions of object code to 

17 execute the protocolp rocess for managing a program fragment downloaded efiteto this en- 

18 beaf dembedded system, as shown in flg sFigs . 2 and 6 described above in the description, when 

19 this on boar d embedded system is interconnected t ewith a terminal and this program is executed 

20 by the microprocessor of this on board embedded system by wa ymeans of the virtual machine. 

21 The invention also concerns a computer program product which can be loaded directly 

22 into the internal memory of a reprogrammable on board embedded system, such as a 

23 microprocessor card with a rewritable memory, as shown with reference to SgFig. 6. This 
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1 computer program product includes portions of object code to execute the stag e s o f steps for 

2 verifying a program fragment downloaded eftteto this on boar d embedded system, as shown and 

3 described above in the description, with reference to flg sFigs . 3a to 3j. This verification is 

4 executed when this on board embedded system is interconnected t ewith a terminal and this 

5 program is executed by the microprocessor of this on board embedded system v kby means of the 

6 virtual machine. 

7 The invention also concerns a computer program product; this computer program product 

8 includes portions of object code to Texecute the stage ssteps of the method of transforming the 

9 object code of a program fragment into standardized object code for this same program fragment, 

10 as shown in SgsFigs. 4a, 4b, 5a, 5b and 6, and described above in the description. 

1 1 The present invention also concerns a computer program product which is r e cord e d stored 

12 on a medium which can be used in a reprogrammable on boar d embedded system, e.g. a 

13 microprocessor e quipp e d provided with a rewritable memory, this on board embedded system 

14 making it possibl ebeing used to download a program fragment consisting of an object code 

15 executable by this microprocessor, by wa ymeans of a virtual machine e quipp e d provided with an 

16 execution stack and local variables or registers manipulated viaby these instructions, to 

17 aHewenable interpretation of this object code. The abovementioned computer program product 

18 includes, at least, a module of programs which can be read by the microprocessor of the en- 

19 beaf dembedded system vi aby means of the virtual machine, to comman d control the execution of 

20 a procedure for managing the downloading of a downloaded program fragment, as shown in 

21 6 gFig . 2 and described above in the description, a module of programs which can be read by the 

22 microprocessor vi aby means of the virtual machine, to command control the execution of a 

23 procedure for verifying, instruction by instruction, the object code which makes up this program 
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1 fragment, as shown and described in relation to flg sFigs . 3a to 3j in the description above, and a 

2 module of programs which can be read by the microprocessor of this on boar d embedded system 

3 vi aby means of the virtual machine, to command control the execution of a downloaded program 

4 fragment following or in the absence of a transformation of the object code of this program 

5 fragment into a standardized object code for this same program fragment, as shown in figFig. 2. 

6 The abovementioned computer program product also includes a module of programs 

7 which can be read by the microprocessor vi aby means of the virtual machine, to comman d control 

8 the inhibition of execution, on the on boar d embedded system, of the program fragment in the 

9 case of an unsuccessful verification procedure efon the abovementioned program fragment, as 

10 shown and described above in the description with reference to fi gFig . 2. 

11 What is claimed is: 
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53 



Code of method 
being verified 



aload 0 




aload 1 




sconst 3 
saload 
putfield C.f 


; : 1 

Pointer to instruction 


J being verified 




return 





± 

Vhort []~ 
C 



Table of register types 



shorx 
"short [)" 



Type stack 



Type stack 
pointer 



TABLE 2 

Pseudo-code of verifier module 



PSEUDO-CODE OF VERIFIER MODULE 

5 

Global variables used: 



7V number of registers declared by current method 

T p maximum size of stack declared by current method 

tr[T r ] table of register types (402 in fig. 4) 

10 tp(T p J stack type (403 in fig. 4) 

pp stack pointer (404 in fig. 4) 

chg flag indicating whether tr has changed 



Initialize pp-f 0 

Initialize tp[0] ... tp[n-\] from types of n arguments of method 
15 Initialize tp[n) ... tp[T r l] to J- 
Initialize chg to true 
While chg is true: 

Reset chg to false 

Position on first instruction of method 
2 0 While end of method is not reached: 

If current instruction is target of a branching instruction: 

If pp # 0, verification fails 
If current instruction is target of a subroutine call: 

If previous instruction continues in sequence, failure 

2 5 Take tp[0) <*- etaddr and pp «-1 

If current instruction is an exception handler of class C: 

If previous instruction continues in sequence, failure 
Do tp[Q]<+ C and pp<r\ 

If current instruction is a target of different kinds: 

3 0 Verification fails 

Determine types a } ... a n of arguments of instruction 
If pp < n, failure (stack overflow) 
For i = 1, n: 

If tplpp-n-i-1] is not subtype of a h failure 

3 5 Dopp^-pp-n 

Determine types r y r m of results of instruction 

If pp+ni±T p , failure (stack overflow) 
For i = 1, m, do tp[pp+i-l] ? n 
Do pp<-pp+m 

4 0 If current instruction is a write to a register r: 



Determine type t of value written to record 
Do fr[r] Mower bound (f, tr[r]) 
If tr[r] has changed, do chg^tnxt 

If current instruction is a branching: 
If pp 4 0, verification failure 

Advance to next instruction 
Return verification success code 



TABLE T3 



static short C3 meth (short [] table ) 
{ 

short □ result = null; 
if (• table length >= 2) result = table; 
return table 



TABLE T4 



First iteration on method code: 



0 

1 

2 
'j 
4 
5 
7 
8 
9 

10 



Mpthnri oodp 

1 V 1 0 LI 1 \J\J V/UUC 


Table of register types 

IrO: sbortU 1 rl: X ] 


a rrtncT fin 1 1 

astore 1 


IrO: short U I rl: X | 


aload 0 


CrO: short U 1 rl: null 1 

1 ■ — 


array lenrth 
sconst 2 




if.scmplt 9 - 


[rO: short U | rl: null j 

r77T>y...f rO: shortlJI rX: null | 


aload 0 


N»(rO: shortUl rl : null | 


astore 1 




aload 1 


CTT.....j r 0; short U Irl : short U| 


axetura 





0 

1 

2 
3 
4 
5 
7 
8 
9 

10 



aconsx^null 



astore 1 



Second iteration on method code: 

[rt: short Uirl: shortTTI 

frO: shcrtU | rl: short U I 

roT short (J f rl : short [J | 

|rO: short CJ 1 rl : shortUj 

|rO: shcrtUtrl: short U I 

frO: short U | rl : short jj| 

rO: short [J | rl: short U | 

rO: shortiJlrl: short [J 1 



aload 0 



array length 



sconst 2 



if.scmplt 9 



aload 0 



astore 1 



aload 1 
aretum 




Stack type 
I 

1 null 1 

1 ' 

1 shcrtU j 
| short | 
{ short 



short 



I 

| short U | 

I 

| shore U | 

I 

I - null | 

I 

| short I) | 
I short I 



1 short I short I 

I ^ 

1 short U j 



|rO: shortUIrl: short U| I short [J | 



TABLE T5 



(a) Violation of type constraints on arguments of an instruction: 

• ( rO: Object | j 



0 : 


aload 0 




1 : 


sconst 1 




o : 


sadd 




3 : 


are turn 





• | rO: Object \ ( Object [ 

rO: Object | | Object j short 

Error: stack type does not 
correspond to what instruction 
expects (short, short) 



(b) Inconsistent use of a register: 



sload 0 



ifeq 6 



accnst.null 



astore 0 



aload 0 




short ) 



null | 



Error: stack type does not correspond 
to what instruction expects (Object) 



10 



(c) Branchings introducing inconsistencies at stack level: 

l 



sload 0 



ifeq 8 



sconst 1 



goto 9 



a const .null 



areturn 




[ rO; short 

| rO: short [ [ short ~] 

| rO: short | | 

[ rO; short 1 [ short 1 

Error: stack not empty at branching point 



(d) Stack overflow within a loop: 

■ fro? 



0 
1 
4 
5 
S 
11 



sload 0 



ifeq ai 



sconst 1 



sine 0 -1 



goto 0 



return 



short 



rO: short 



rO: short 



' 1 short 



rO: short 



short 



short 



short 



Error: stack not empty at branching point 



TABLE T6 

(a) Initial code of method, annotated by types of registers and of stack: 

rO: Object \ \ 

(Object] 



0 : 


aload 0 


1 : 


ifnull 8 - 


4 : 


iconst 1 


5 : 


goto 9 — 


8 : 


iconst 0 


9 : 


ineg 


10 : 


istore 0 


11 : 


iload 0 


12 : 


iretura 



• | rO: Object 

. j rO: Object | | 

■ f rO; Object! f int I 

■ 1 rO: Object \ \ 

- I rO: Object | 1 int | 

- 1 rO: Objectl I int | 



rO: int 
rO : int I 



int 



J 



TABLE T7 



(b) Method code after standardization of stack at branching 5 -» 9: 







aload 0 




ifnull 8 - 




iconst 1 




•••( rO: Object | rl: ± \ 


istore 1 




... rO: Object | rl: int | 


goto 8" - 




^rO: Object | rl: int | 


iconst 0 




rO: Object | rl: ± \ 


istore 1 




— ( rO: Object | rl: int j 


iload 1 


I.-.' [ rO: Object | rl : int | 


ineg 




istore 0 


rO: int | rl: int j 


iload 0 


( rO: int | rl: int j 


iretum 





TABLE T8 

(c) Method code after reallocation of registers: 



0 : 


aload 0 


j rO: 


Object | 


rl: 






1 
















1 : 


ifnull 8 - 


1*0: 


Object ( 


rl: 




1 


Object) 


4 : 


i const 1 


^5V....| rO: 


Object | 


rl : 


1 


1 


| 


4' : 


istore 1 




-I rO: 


Object | 


rl: 


JL 






o : 


goto 8" - 




)••• rO: 


Object j 


rl: 


int 


• j 


| 


8 : 


i const 0 




'j rO: 


Object | 


rl : 


int 


i 


















8' : 


istore l 




-1 rO: 


Object | 


rl: 


± 


1 


[ i« | 


3 M : 


iload 1 




L-jrO: 


Object j 


rl: 


int 






9 : 


ineg 


( rO: 


Object | 


rl: 


int 




1 i« 1 


10 : 


istore l 


f rO: 


Object | 


rl: 


ant 


1 


I i" | 


11.: 


iload 1 


| rO: 


Object | 


rl: 


int 


I 




12 : 


iretura 


| rO: 


Object 


rl: 


int 


1 


I int 















TABLE • T9 

(a) Branching target, previous instruction not continuing in sequence: 
Branching Branching 



non-i 



instr. 



instruction i 



stack state 



Standardization 



non-seq. instr. 



load rj 



load 



instruction i 



stack state 
I 

EE 



TABLE T10 



(b) Branching target, previous instruction continuing in sequence: 



Branching 



seq. instr. 



instruction t 



Branching 




S3 

0 

I 

B 
CHS 



TABLE Til 

(c) Unconditional branching without arguments: 

Standardization 



r 

Target 



goto 



r 



Target 



store r 2 



store rj 



goto 



HDD 

I 



TABLE T12 



1 0 (c) Conditional branching with one argument: 



r 

Target 



if eq 



Standardization 



EES 



r 

Target 



svap.x 2,1 



store r 2 



5 tor© rj 



if eq 



load r\ 
load r 2 



IPIQIOI 

ED 
I 

0 
S3 



